Date: Sun, 12 Dec 93 04:30:28 PST
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V93 #144
To: Ham-Digital


Ham-Digital Digest          Sun, 12 Dec 93       Volume 93 : Issue  144

Today's Topics:
                9k6 baud packet - is there any point?
                    COMPLETE Documented NOS Wanted
            Modifying the 16550 chips on the RS-232 cards
          Need advice on using tube-final rigs for RTTY/AFSK
                   Q: G3RUH 9600 and Kenwood TM721

Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Thu, 9 Dec 1993 07:15:38 +0000
From: pacbell.com!sgiblab!swrinde!cs.utexas.edu!howland.reston.ans.net!pipex!uknet!demon!llondel.demon.co.uk!dave@network.ucsd.edu
Subject: 9k6 baud packet - is there any point?
To: ham-digital@ucsd.edu

In article <FROUD.93Dec8202731@sunlab41.sx.ac.uk> froud@sunlab41.sx.ac.uk (How much wood could a woodchuck chuck if a woodchuck could chuck wood?) writes:
>Just a minor point I wouldn't mind cleared up if anyone has a few seconds...
>
>I read that rigs had to be modified to allow upwards of 2k4 baud transmission,
>but is this pointless if the person you are trying to commmunicate with
>hasn't a repicrocal modification at the either end to allow reception of
>higher baud transmissions?
>
Unlike land-line modems, there is no speed negotiation on packet (unless you
are using strange kit) so you have to set up your rig/TNC to work at a 
particular speed. Once you have tried 9600baud you will think that 1200 is
*very* slow. It isn't hard to modify rigs either....

Dave
-- 

*****************************************************************************
* G4WRW @ GB7WRW.#41.GBR.EU AX25     *    Start at the beginning. Go on     *
* dave@llondel.demon.co.uk  Internet *     until the end. Then stop.        *
* g4wrw@g4wrw.ampr.org      Amprnet  *      (the king to the white rabbit)  *
*****************************************************************************

------------------------------

Date: 10 Dec 1993 12:41:00 GMT
From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!pipex!uknet!warwick!unicorn.nott.ac.uk!unicorn.nott.ac.uk!eeyimkn@network.ucsd.edu
Subject: COMPLETE Documented NOS Wanted
To: ham-digital@ucsd.edu

Hi folks,
You might like to know that I'm currently working on a (relatively brief) guide
to getting up and running with NOS, provisionally entitled 'NOS for Dummies'.
This may change :-)

It won't cover nearly as much in depth as Ian's book, but should be able to help
with the basics of starting up. It'll be freely available as TeX source or
Postscript. I started it earlier this year as a mini-project, but it's grown out
of all proportion, so I'll probably finish it some time next spring, depending on
whether I include the stuff about running IP through Linux or not, and on how
long it takes for me to finish porting the existing text from Micro$oft Word to
TeX..

73 Mike G7GPA

-- 
+- Mike Knell, University of Nottingham, UK -=- M.Knell@unicorn.nott.ac.uk --+
|  --THIS SPACE TEMPORARILY BLANK--   | AMPR: g7gpa@hobbes.g7gpa.ampr.org    |
| (until I can think of a decent joke)| AX25: g7gpa@g7gpa.gb7bad.#23.gbr.eu  |
|UNDER the overpass! OVER the underpass! Around the future and BEYOND REPAIR!|

------------------------------

Date: Thu, 9 Dec 1993 19:18:51 GMT
From: das.wang.com!wang!garyf@uunet.uu.net
Subject: Modifying the 16550 chips on the RS-232 cards
To: ham-digital@ucsd.edu

postmaster@asarin.ORG.AR writes:

>===============================================================================
>Modifying the 16550 chips on the RS-232 cards

>-----------[ Now, the file 16550mod.txt ]--------------------------------------

>Notes on a modification to PC's using the INS16550A UART IC for reception of
>9600bps data from the UO-22 satellite. These form the basis of an article to
>be published in Amsat-UK's journal OSCAR NEWS to whom permission to copy this
>article, and the accompanying diagram, for publication should be sought.

>Background
>==========
>Most PC's use the 16450 UART IC for serial communications (also equivalent to
>the INS8250A and CMOS versions of both). With the advent of 9600bps satellite
>communications some folks, especially with slower PS's, noticed that they got
>errors on the TNC-to-PC link; this shouldn't happen ! The finger of suspicion
>pointed to the software making disk accesses and missing receive data whilst
>doing so. The 16550A UART (and CMOS 82C550A) is functionally equivalent to the
>16450 but has an internal FIFO store holding 16 bytes of data and someone put
>the thought forward to try it. It certainly cleared up problems for some folks
>but others had a change of symptom; PB would just stop receiving even though
>data was coming from the TNC to the PC. After much research and international
>co-operation I think we have a hardware solution to these problems.

>The solution supposes that the reason for the apparent freezing of PB is due
>to the fact that the 16550A interrupt line goes high to assert and stays high
>until the interrupt is serviced. (The more common 16450 IC also does this; I
>don't know why PC's don't freeze with it.) If the PC is serving another
>interrupt at the time the 16550A asserts then the new one doesn't get to be
>seen ... hence no receive data. I have actually seen this happen on an
>oscilloscope and the interrupt line was stuck high at the time of the freeze.

Your observation is correct, but there is a simple software solution to the
problem. The basic problem is that the IBM PC uses edge triggered interrupts
instead of level triggered ones (I'd like to strangle the guy at IBM who
made that decision). A properly written COM port driver should clear the
interrupt as early in the interrupt handler as possible and then just before
re-enabling interrupts and exiting it should check whether any additional
characters are available and if there are, read those too.

>The earlier belief that the FIFO needs to be switched ON is not correct, the
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yes it is! The FIFO does NOT default to being used. The COM port driver (BIOS)
needs to be 16550 aware and enable the FIFO. The reason it doesn't default to
ON is that software that is not aware of the FIFO would get confused by it.


>FIFO in the 16550A is operative all the time; the software issued some time
>ago merely sets different TRIGGER levels for the UART's "data available" flag.

It looks like you did a lot of work on this, but I think you got carried
away with a hardware fix for a software problem.

Gary
--
--/*   Gary A. Field - WA1GRC, Wang Labs M/S 019-72B, 1 Industrial Ave      
   Lowell, MA 01851-5161,  (508) 967-2514, email: garyf@wiis.wang.com, EST5EDT
                   A waist is a terrible thing to mind!    */

------------------------------

Date: Wed, 8 Dec 1993 14:19:15 GMT
From: olivea!sgigate.sgi.com!sgiblab!swrinde!emory!kd4nc!ke4zv!gary@decwrl.dec.com
Subject: Need advice on using tube-final rigs for RTTY/AFSK
To: ham-digital@ucsd.edu

In article <2e1o5h$n77@klaava.Helsinki.FI> stickler@klaava.Helsinki.FI (Patric M Stickler) writes:
>I'll be shopping for a used rig soon and will be on a very tight
>budget, so I'm trying to get a picture of what the minimal rig would be
>that will do what I want. Other than SSB/CW, I've been itching to get
>into RTTY, but have heard that many older rigs have problems both from
>the 100% duty cycle and sluggish operation.
>
>I'm intrested in hearing people's experiences working the various
>digital modes on HF using older tube rigs, or rigs with tube finals.
>More than likely, I'll be using a late-model multimode TNC and AFSK for
>HF RTTY/Baudot/AMTOR. What sort of things should I look for in a
>suitable rig. Obviously, the quality of the SSB signal is more
>important when using AFSK rather than FSK (right?). How can one
>estimate the max. drive the finals can take at 100% duty cycle? How
>can one determine if the tx is "fast" enough (or is sluggishness
>only a problem with FSK and not AFSK?).

Ok, I use two different rigs for the HF digital modes. I use the
IC735 and a B&W6100 and Drake R4C. The former is, of course, a
modern solid state transceiver. It performs well on all the digital
modes. It has IF shift that allows the narrow filter to be positioned
correctly for the digital tones even in SSB mode. It will allow either
AFSK or FSK transmission. FSK is generally preferred. It switches 
quickly enough for AMTOR. For RTTY, drive should be reduced to 50
watts output. For AMTOR and packet, full power is OK since it has
an excellent thermal design.

The B&W6100 uses a pair of 6146Bs in the final and is rated at 
180 watts PEP in SSB mode. It too needs to be throttled back to
50 watts for RTTY, and can handle about 120 watts AMTOR or packet.
When I used the Drake T4X, it was necessary to throttle back the
sweep tube finals to about 20 watts for RTTY because their dissipation
is insufficient for higher power steady carrier use. In general, use
the manufacturer's recomendation for AM voice power level for RTTY.
If you don't have the manual, divide normal *average* SSB power levels 
by 2 for real transmitting tubes, and by 4 for sweep tubes. Average
power under SSB is very difficult to characterize because it's fundamentally
tied to voice characteristics. A good rule of thumb is that it's 20% of
the *input* PEP rating. AMTOR and packet, because they transmit intermittantly,
can use somewhat higher power levels.

Radios that use open frame TR relays can be a problem for AMTOR, but
not always. Often it is the AF stage recovery time that dominates
the TR turnaround. Open frame relays can be fast enough, and vacuum
relays always are fast enough. In rigs that switch the B+ to the
receiver, you may need to change the value of power supply decoupling
capacitors in order to get a short enough time constant for receiver
recovery. Or, you can modify the TR switching so that B+ stays hot
and mute the receiver another way. That's the method I normally use.

Don't be concerned about the apparent low power levels on RTTY. It
doesn't take a lot of power to get good print at intercontinental
distances providing the other station has a good TU, not a PK232
or KAM. Something like an ST-6 does wonders for digging out signals
that are below the noise to the ear. The PK232 will allow you to
put an external modem ahead of it, so using a ST-6 with it is an
option. I don't think the KAM will support that without modifications.
And of course for RTTY all you need is the ST-6 and a modem program
that supports Baudot running on your computer, or an honest to God
old mechanical teletype. The ST-6 will also work with some of the
packet programs that do the bit banging in software. I don't know
of any software only AMTOR programs so you're stuck with using the
PK-232 as the protocol engine in that case. Some of the newer DSP
boxes may be as good, or better, than the ST-6, but I haven't done
a side by side test yet.

Gary
-- 
Gary Coffman KE4ZV          | I kill you,             | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems | You kill me,            | uunet!rsiatl!ke4zv!gary
534 Shannon Way             | We're the Manson Family | emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     |         -sorry Barney   | 

------------------------------

Date: 8 Dec 93 11:30:53 GMT
From: metro!basser.cs.su.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!news.kei.com!ddsw1!library.ucla.edu!news.mic.ucla.edu!ctc.com!pitt.edu!gatech!howland.reston.ans.@munnari.oz.au
Subject: Q: G3RUH 9600 and Kenwood TM721
To: ham-digital@ucsd.edu

I am looking for info about connecting 9600 modem type G3RUH to a Kenwood TM721A.

Thanks in advance,

4X1BQ, Yossi Sharon

Internet: yosi@eng.tau.ac.il
Packet:   4X1BQ@4X1RU.isr.mdle

------------------------------

Date: 11 Dec 1993 01:29:21 -0800
From: ukma!nntp.msstate.edu!olivea!apple.com!apple.com!not-for-mail@seismo.css.gov
To: ham-digital@ucsd.edu

References <1993Dec6.174733.27968@mixcom.mixcom.com>, <2e3vpa$dg9@spock.usc.edu>, <jschulma.21.000F2EAC@uiuc.edu>du
Subject : Re: When will we get digital cellular?

In article <jschulma.21.000F2EAC@uiuc.edu>,
Jay S. Schulman <jschulma@uiuc.edu> wrote:
>Speaking as someone who has been testing digital for a few months for 
>Motorolla, it is not what it is cracked up to be.  Don't get me wrong, in a 
>few years digital cellular will be what analog is today.  But, right now, 
>digital sounds terrible!  It sounds like you are talking into a cheap computer 
>and listening to the playback.  Besides heavy hissing and other background 
>noice, your voice alone makes it difficult for others to understand you.  

Sounds like TDMA cellular is really awful at this point! I tried a
CDMA phone during a test one day and the audio quality was just fine--
even with 50 or 60 other people using the same channel at the same time.


>To anyone considering digital:
>
>          Wait.  It will get much better in the future.

I guess how far in the future you'll have to wait for decent 
quality depends on which type of digital cellular is being
installed in your area. :-)


Patty

-- 
============================== Patty Winter ==============================
 Apple contractor             Internet: winter@apple.com
 Sunnyvale, California           AMPRNet: 44.4.4.50
   "What about truth? What about reality?" 
  "What about the way the old ending tested in Canoga Park?"
================================== N6BIS =================================

------------------------------
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******************************
******************************
